1.1 Accessibilité multimodale

L’accessibilité est un concept utilisé en géographie pour qualifier “la plus ou moins grande facilité avec laquelle ce lieu peut être atteint à partir d’un ou de plusieurs autres lieux, par un ou plusieurs individus susceptibles de se déplacer à l’aide de tout ou partie des moyens de transport existants” (Laurent Chapelon in Encyclopédie Hypergeo).

Etudier l’accessibilité multimodale d’un lieu ou d’un ensemble de lieux revient donc à mesurer puis à comparer les possibilités de déplacement et la pénabilité associée à ces trajets en tenant compte de l’ensemble des modes de transport disponibles : transports en commun, à pieds, à vélo, ou en voiture, notamment.

1.2 Le projet OpenTripPlanner

OpenTripPlanner est un logiciel libre développé en Java permettant de créer et d’interroger un planificateur d’itinéraire multimodal personnalisé. Créé en 2009 par TriMet, l’agence de transport en commun de Portland (Oregon), il s’est ensuite développé, et englobe aujourd’hui une communauté mondiale d’utilisateurs et de développeurs.

L’analyse de l’accessibilité par des réseaux de transport multimodaux, opérant à différentes échelles et gérés par des autorités organisatrices variées, marque une étape importante dans le champ de la géographie des transports. Les déplacements optimaux déterminés par OTP correspondent au plus court chemin, c’est-à-dire à la minimisation du temps de déplacement pour l’usager (algorithmes de Dijkstra (Dijkstra et al. (2021)), A* (Hart et al. (1968)) et assimilés). L’intermodalité au sein d’un même réseau (intramodalité) ou entre des réseaux différents est également intégrée dans OTP, avec la gestion optimale des correspondances (minimisation du temps de marche entre deux arrêts, du temps d’attente aux arrêts, etc.). OTP se prête donc aux analyses territoriales de l’accessibilité, en simulant les meilleurs déplacements possibles pour l’usager en fonction des différents modes de transport qu’il a à sa disposition pour un horaire donné.

Briévement, OTP construit un graphe décrivant les itinéraires reliant l’ensemble des localisations d’un territoire donné, en transport en commun comme par la route, à partir de données General Transit Feed Specification (GTFS) pour le réseau de transport en commun (bus, métros, tramways, trains) et de données OpenStreetMap pour les modes de déplacement routiers (voiture, vélo, piéton). Le logiciel dépend donc de données ouvertes renseignées dans des formats de fichiers standards. Sur ce point, rappelons que les autorités organisatrices de la mobilité (AOM) ont l’obligation de transmettre leurs données de l’offre de transport (règlement européen 2017/1926, art. 25 de la LOM de 2019) sur le point d’accès national (PAN).

Le code source d’OTP est publié en accès libre sur la plateforme Github.

1.3 Ressources

Les principales ressources recommandées en complément de ce tutoriel sont disponibles aux liens suivants :

• Morgan et al. (2019) https://joss.theoj.org/papers/10.21105/joss.01926

• https://docs.ropensci.org/opentripplanner/articles/prerequisites.html

• https://docs.ropensci.org/opentripplanner/articles/advanced_features.html

• Pfertner et al. (2023) https://www.mdpi.com/2071-1050/15/3/1947

2.1 Les données GTFS

2.2 Les données OpenStreetMap

L’utilisation du réseau viaire (routes, chemins) est indispensable pour calculer les itinéraires des modes individuels (voiture, piéton et cycliste) et des modes collectifs (pré et post-acheminement, gestion des correspondances). Pour cela, nous utiliserons les données issues du projet de cartographie collaborative OpenStreetMap (OSM).

La complétude et la précision des données varient d’un territoire, d’une échelle géographique et d’une temporalité à l’autre, à ce propos on lira par exemple Herfort et al. (2022). Il faut donc être vigilant à cet aspect en amont de leur utilisation dans le cadre d’une analyse d’accessibilité qui utilise le réseau viaire. En France, la plateforme recense l’ensemble des données géographiques publiques en Open Data en complément de l’information géographique volontaire. Une présentation des données OSM est par exemple proposée par Mericskay (2017).

library(osmextract)

library(sf)
EPCI_3M <- st_read("data/EPCI_MONTPELLIER.geojson")

Reading layer `MMM_MMM_Limites' from data source 
  `C:\Users\jcull\Desktop\Divers\Rzine\Rzine_OTP\data\EPCI_MONTPELLIER.geojson' 
  using driver `GeoJSON'
Simple feature collection with 31 features and 2 fields
Geometry type: MULTIPOLYGON
Dimension:     XY
Bounding box:  xmin: 3.656507 ymin: 43.46704 xmax: 4.066007 ymax: 43.76709
Geodetic CRS:  WGS 84

OSM_3M_url <- oe_match(EPCI_3M) 

oe_download(
file_url = OSM_3M_url$url,
file_size = OSM_3M_url$file_size,
#provider = "test",
download_directory = tempdir()
)

OSM_highways <- sf::read_sf("C:\\Users\\33658\\AppData\\Local\\Temp\\RtmpCYFlTP\\geofabrik_languedoc-roussillon-latest.osm.pbf", layer = "lines", query = "select highway from lines")

2.3 Relations entre données GTFS et OSM.PBF

Si un arrêt d’un GTFS se trouve dans un bâtiment, il est nécessaire d’être vigilant à sa connexion au graphe piéton, sans quoi l’isolement de l’arrêt rendra impossible les parcours à pied puisque l’impossible de créer des pré- et post-acheminements en dehors du bâtiment ne permettront pas l’identification de correspondances.

Par exemple, les cheminements piétons dans les gares ne sont pas systématiquement renseignés dans OpenStreetMap, ni les escaliers ou ascenseurs permettant de changer de quai. D’expérience, les gares les plus importantes sont correctement géoréférencées mais toutes ne le sont pas. Un arrêt isolé du graphe piéton ne permet pas au logiciel de comprendre qu’il peut entrer et sortir de la gare, ou réaliser une correspondance entre un TGV et un TER dans la même gare s’il doit se déplacer dans celle-ci, faute d’un graphe piéton disponible.

Il nous semble que deux solutions peuvent alors être envisagées :

• Contribuer à OpenStreetMap pour ajouter les informations manquantes. Les données .osm.pbf de la Geofabrik sont mises à jour tous les jours ;

• Modifier la localisation du point d’arrêt créé par le GTFS. Cela peut être intéressant pour déplacer un arrêt avec des coordonnées imprécises. Ainsi, le point peut être replacé dans un espace accessible au graphe piéton, comme l’entrée de la gare. Les coordonnées des arrêts sont rangées dans le fichier stops.

3.1 La librairie opentripplanner

OTP étant défini en Java, son fonctionnement nécessite l’entrée de lignes de commandes Java. La librairie opentripplaner permet de définir les paramètres de ces fonctions depuis R et de les traduire automatiquement en Java.

La version de la librairie utilisée pour ce tutoriel est la 0.5.0, publiée en janvier 2023 et téléchargée depuis le CRAN le 27 mars 2023. Son exécution nécessitera l’installation préalable de Java 8 sur la machine. Attention, des conflits avec des versions postérieures ou ultérieures de Java sur votre machine sont à attendre, il est donc recommandé de désinstaller ces versions en amont de l’installation de Java 8 et du lancement d’OTP.

library(opentripplanner)

Cette partie du tutoriel est basée sur la documentation proposée par Marcus Young, Malcom Morgan et Robin Lovelace, les développeurs du package.

3.2 Installation d’OTP

Nous allons donc utiliser OTP en local, en téléchargeant la dernière version du logiciel depuis R.

path_data <- file.path("data/OTP")

download_otp <- otp_dl_jar(path = path_data, cache = FALSE)

path_otp <- paste(path_data,"/otp-1.5.0-shaded.jar", sep="")

3.3 Préparation des fichiers d’entrée

En amont de la création du graphe sur lequel les calculs d’itinéraires seront réalisés par OTP, il est nécessaire de regrouper les fichiers d’entrée au sein du répertoire contenant le fichier JAR :

• créer un sous-répertoire nommé graphs (/graphs)

• à l’intérieur du sous-répertoire graphs, créer un nouveau sous-répertoire nommé default (/graphs/default)

• dans le sous-repétoire default, déposer le fichier osm.pbf du Languedoc-Roussillon et le fichier contenant les données GTFS au format zippé (gtfs.zip)

3.4 Création du graphe

Afin de construire les itinéraires, OTP reconstitue via la fonction otp_build_graph() un graphe des cheminements possibles à partir des données d’entrée susmentionnées. Ce graphe permettra de gagner un temps substantiel pour démarrer de nouvelles sessions d’OTP, à la manière d’une sauvegarde des réseaux.

Le paramètre otp indique le chemin d’accès vers l’archive java d’OTP (fichier OTP .jar).

Le paramètre dir indique le chemin d’accès vers le répertoire contenant les fichiers nécessaires à la génération du graphe.

Le paramètre memory prend un nombre entier qui renseigne sur la quantité de mémoire à attribuer à OTP (par défaut 2048 MB). La quantité de mémoire dépend de la taille de l’espace géographique à l’étude, de la puissance de votre machine et de la version de Java utilisée (idéalement du 64bit, vous serez limités à quelques GB si vous utilisez le 32bit).

Le territoire métropolitain de Montpellier correspond à un espace géographique de taille intermédiaire, nous allons donc demander à utiliser 10GB de mémoire (c’est-à-dire 10000MB).

Notons ici qu’OTP est optimisé pour réaliser des routages à l’échelle d’une ville et que ses performances se dégraderont avec de plus grandes zones.

otp_build_graph(otp = path_otp, dir = path_data, memory = 10000)

Une fois le graphe construit, il est recommandé de passer la ligne en commentaire afin de ne pas relancer la procédure à chaque exécution du code.

3.5 Synthèse de l’organisation du dossier OTP

Nous pouvons résumer l’organisation du dossier OTP avec ce schéma :

Un fichier router-config.json, facultatif pour démarrer une session OTP, pourra être ajouté dans un second temps pour modifier des paramètres de déplacement (voir partie 4.5). Egalement, le fichier Graph.obj est facultatif mais il est intéressant de le créer, une fois la session OTP en fonctionnement, pour gagner du temps au demarrage pour les prochaines sessions.

Pour reproduire le prochain exemple, le répertoire OTP et les données sont disponibles ici :

Télécharger les données

4.1 Générer une instance locale du serveur OTP

Il est ensuite nécessaire d’installer une instance locale du logiciel. Nous la crééons grâce à la fonction otp_setup(), qui lance le calculateur d’itinéraires (default router) par défaut via une interface web. Cette procédure peut prendre quelques minutes.

OTP dispose d’un serveur Web Grizzly intégré qui s’exécute sur les ports 8080 (http) et 8081 (https). Les options port et securePort de la fonction permettent d’indiquer des ports alternatifs si les ports par défaut sont utilisés par d’autres applications en cours.

otp_setup(otp = path_otp, dir = path_data)

La session d’OTP est alors démarrée en local, et une fenêtre s’ouvre dans un navigateur internet afin d’accéder à l’interface graphique du logiciel.

L’interface graphique de l’application Web d’OTP permet de zoomer/dézoomer sur l’espace d’étude, de spécifier des dates et des temps de trajet, le mode de transport à considérer (et d’en paramétrer l’usage), ou encore de modifier le fond de carte.

4.2 Paramétrer une requête depuis l’interface graphique

Pour rechercher un itinéraire depuis OTP, il est possible de désigner les lieux d’origine et de destination par leurs couples de coordonnées de longitude et de latitude ou de renseigner des noms d’arrêts issus des données d’entrée.

Pour définir un point de départ, sans en connaître les coordonnées de longitude/latitude ou le nom d’arrêt au préalable, il est possible de le sélectionner directement depuis la fenêtre graphique comme suit :

Notons ici l’importance des bornes temporelles de validité des fichiers GTFS dans l’obtention d’une réponse à une requête. OTP ne sera en effet pas en capacité de trouver un trajet pour des périodes en amont ou en aval des dates renseignées dans le fichier calendar.

D’autres paramétrages sont directement accessibles depuis l’interface, comme l’illustre l’exemple ci-dessous.

4.3 Connecter R à l’instance locale d’OTP

Afin d’automatiser les procédures, il est intéressant d’exécuter OTP depuis R, en lui soumettant des lignes de commande personnalisées.

La fonction otp_connect() permet de tester et de créer une connexion à OTP depuis R. Plusieurs paramètres peuvent lui être passés en option, tel que le fuseau horaire (timezone) à partir duquel construire les requêtes (par défaut, la valeur est celle de votre machine), la version d’OTP (par défaut, la version renseignée est 1.5), ou encore le port utilisé pour la connexion (par défaut, le numéro de port utilisé est 8080).

myOtpcon <- otp_connect(timezone = "Europe/Paris")

4.4 Arrêter l’instance locale d’OTP

Le lancement d’OTP a automatiquement démarré Java, qui s’exécute donc hors de l’environnement R. Il faut donc penser à arrêter OTP et Java lorsque l’on quitte la session R à partir de laquelle une session OTP avait été lancée. On utilise pour cela fonction otp_stop().

Un message s’affiche, afin de valider la clotûre de Java induite par la commande otp_stop() : “This will force Java to close, Press [enter] to continue, [escape] to abort”. Notons ici qu’en pressant sur [enter], toutes les applications utilisant Java seront arrêtées.

otp_stop()

4.5 Configurer les options de déplacement

router_config <- otp_make_config(type = "router")  

router_config$routingDefaults$walkSpeed <- as.numeric(0.84)

router_config$routingDefaults$bikeParkTime <- as.integer(120)

otp_validate_config(router_config)

[1] TRUE

otp_write_config(router_config,                
                 dir = path_data,
                 router = "default")

otp_stop()
otp_setup(otp = path_otp, dir = path_data, router="default")
myOtpcon <- otp_connect(timezone = "Europe/Paris", router="default")

route_bis <- otp_plan(otpcon=myOtpcon, 
                  fromPlace = c(3.87943, 43.60844), 
                  toPlace = c(3.96915, 43.54009),
                  mode = "WALK",
                  date_time = as.POSIXct("2023-04-19 10:15:00"))

route$walkDistance/route$duration

5.1 Requête unique

La fonction otp_plan() permet d’obtenir un ou des itinéraires connectant un point d’origine (fromPlace) à un point d’arrivée (toPlace). Tout comme sur l’interface graphique, les lieux sont définis par un couple de coordonnées de longitude et de latitude, à la différence qu’ici les latitudes sont renseignées en premier et les longitudes ensuite. On combine classiquement ces deux valeurs dans un vecteur via la fonction c() (combine).

Notons que pour utiliser des noms d’arrêts comme lieu de départ et d’arrivée, il faut remplacer les arguments fromPlace/toPlace par les arguments fromID/toID.

L’argument otpcon renseigne l’objet de connexion OTP produit avec la fonction otp_connect().

L’argument mode désigne les modes de transport à considérer pour le calcul de l’itinéraire : TRANSIT (déplacement en transport en commun, tous modes confondus), BUS (déplacement en bus), TRAM (déplacement en tramway), RAIL (déplacement en train), WALK (déplacement piéton), BICYCLE (déplacement à vélo), CAR (déplacement en voiture), etc. Par défaut, le trajet est calculé pour un voyage en voiture.

Il est possible d’indiquer des combinaisons de modes de déplacement (parmi les options proposées par OTP). Par exemple, une combinaison c("CAR","TRANSIT") permet de décrire des trajets de type Kiss and ride, où un usager est déposé en voiture à une station de transport en commun sans avoir lui-même à garer le véhicule automobile. La combinaison c("CAR_PARK","TRANSIT") permet quant-à-elle de décrire des trajets pour lesquels l’usager se déplace en voiture jusqu’à un parking relais à proximité d’un arrêt de transport en commun puis emprunte ce réseau.

Le paramètre date_time renseigne la date et l’heure de départ au format POSIXct. Par défaut, la date et le jour courants sont utilisés.

D’autres paramètres optionnels sont proposés, parmi lesquels :

• maxWalkDistance qui indique le nombre de mètres maximal à parcourir à pieds sur l’ensemble du trajet ;

• arriveBy qui permet de définir l’heure d’arrivée (arriveBy = TRUE) via le paramètre date_time plutôt que l’heure de départ (par défaut, arriveBy = FALSE) ;

• numItineraries qui permet de restreindre le nombre d’itinéaires en sortie.

route <- otp_plan(otpcon=myOtpcon, 
                  fromPlace = c(3.87943, 43.60844), 
                  toPlace = c(3.96915, 43.54009),
                  mode = "BICYCLE",
                  date_time = as.POSIXct("2023-04-19 10:15:00"))

Le résultat de la requête est un tableau de données (dataframe) décrit au format simple features de la librairie du même nom (sf).

library(DT)
datatable(route)

Le chemin proposé est composé de trois étapes (legs) de déplacement continu utilisant un même mode, recensés dans l’ordre du cheminement. La somme de leurs distances et de leurs durées correspond ainsi à la distance (en mètres) et à la durée (en secondes) du trajet total :

sum(route$leg_distance)
sum(route$leg_duration)

5.2 Requêtes multiples

L’intérêt d’instruire des requêtes OTP par lignes de commande est certainement de pouvoir générer des demandes multiples, par exemple, en étudiant les temps de trajet nécessaires pour se déplacer d’une origine à une destination à différents moments de la journée, en définissant une liste de lieux de départ pour un même lieu d’arrivée ou encore pour des plages horaires différenciées.

Le format des paramètres fromPlace et toPlace peut être varié : couple de paires de longitude/latitude, matrice à deux colonnes décrivant les paires de longitude/latitude ou encore un fichier d’information géographique au format sf contenant des géométries ponctuelles décrites dans le CRS 4326.

start_places <- as.matrix(rbind(c(3.86459,43.69760),c(4.01288,43.66112)))

end_places <- c(3.89695,43.59880)

route_2 <- otp_plan(otpcon=myOtpcon, 
                  fromPlace = start_places, 
                  toPlace = end_places,
                  mode = c("TRANSIT","WALK"),
                  date_time = as.POSIXct("2023-04-19 10:15:00"))

La localisation des trajets peut aisément être obtenue et cartographiée. L’exemple ci-dessous utilise la fonction annotation_map_tile() de la librairie ggspatial afin d’ajouter un fond à la carte générée via la fonction geom_sf()de la librairie ggplot2. La carte proposée n’est pas mise en page, elle permet seulement de faire un rapide diagnostic visuel. La liste des fonds de carte disponibles est accessible via la fonction rosm::osm.types().

library(ggplot2)
library(ggspatial)
ggplot() +
  annotation_map_tile(zoom = 13) +
  geom_sf(data = route_2, col = "red", size=1.5) +
  annotate(geom="point", x = end_places[1], y = end_places[2], colour = "black", size = 2)

L’usage de l’argument get_geometry = FALSE dans la fonction otp_plan() permet, à l’inverse, d’abandonner leur géométrie. Cette action permet notamment de gagner en temps de calcul lorsque les lieux sur lesquels opérer les requêtes sont nombreux et que l’on s’intéresse aux attributs des trajets.

route_3 <- otp_plan(otpcon=myOtpcon, 
                  fromPlace = start_places, 
                  toPlace = end_places,
                  mode = c("TRANSIT","WALK"),
                  date_time = as.POSIXct("2023-04-19 10:15:00"),
                  get_geometry=FALSE)

library(dplyr)
route_3b <- route_3 %>% 
  distinct(fromPlace,route_option, .keep_all = TRUE) %>%
  select(fromPlace,toPlace,duration) 

library(tidyr)
time_matrix <- pivot_wider(data = route_3b, names_from = toPlace, values_from = duration) 

On peut également choisir de ne garder au sein de la matrice que la durée de trajet minimale pour chaque couple d’origine/destination. L’usage des coordonnées géographiques pour désigner les lieux d’origine et de destination n’est ni usuel, ni pratique. Nous allons donc également les modifier.

route_3c <- route_3 %>% 
  distinct(fromPlace,route_option, .keep_all = TRUE) %>%
  select(fromPlace,toPlace,duration) %>%
  group_by(fromPlace) %>% slice(which.min(duration))

route_3c$fromPlace <- c("Ori_1","Ori_2")
route_3c$toPlace <- "Dest_1"

time_matrix_2 <- pivot_wider(data = route_3c, names_from = toPlace, values_from = duration)

Ces matrices peuvent par exemple être retranscrites graphiquement sous la forme de cercles proportionnels au temps de trajet entre les lieux.

# passage de la matrice au format long pour faciliter sa mise en page graphique via la fonction melt de la librairie reshape2
library(reshape2)
tabCont_time_matrix_2 <- melt(time_matrix_2) 

# construction d'un graphique en cercles proportionnels avec la librairie ggplot2
library(ggplot2)
ggplot(tabCont_time_matrix_2, aes(x = variable,
                  y = fromPlace)) +  
  geom_point(aes(size = value), color="blue")  +
  scale_size(range=c(2,4),   
             breaks=c(4431,4981), 
             labels=c("4431","4981"), 
             name = "Temps (sec)",
             guide="legend") +
  labs(title="Durée estimée des trajets", 
       x="Destination",
       y="Origines") +
  theme_minimal() 

5.3 Cartes d’itinéraires interactives

Le code ci-dessous présente un exemple de cartographie interactive réalisée avec la librairie leaflet pour R.

Pour centrer la carte, nous allons utiliser les données géospatiales décrivant les contours de la métropole de Montpellier. Leaflet nécessitant une projection en Pseudo-Mercator, nous utilisons la fonction st_transform() de la librairie sf afin de transformer le SCR de la couche.

Les fonctions st_centroid() et st_coordinates() de la librairie sf permettent respectivement de définir le centroïde du polygone et d’en récupérer les coordonnées au sein d’une matrice. Les longitudes sont données dans la première colonne et les latitudes dans la seconde.

Notons que le GeoJSON EPCI_3M a été téléchargé et chargé dans la partie 2.2.1.

EPCI_3M_4326 <- st_transform(EPCI_3M, 4326)
cent3M <- st_centroid(EPCI_3M_4326)
lat3M <- median(st_coordinates(cent3M)[,2])
lon3M <- median(st_coordinates(cent3M)[,1])

Nous faisons ensuite appel aux fonctionnalités de la librairie leaflet afin de construire la carte interactive de l’objet route que nous venons de créer :

• setView() permet de définir la vue de départ, en indiquant son centre géographique par un couple de coordonnées et un niveau de zoom allant de 0 (monde) à 18 (rue) ;

• addPolylines() permet d’ajouter des objets géographiques de type polylignes. Par défaut, les géométries sont celles des données renseignées dans la fonction leaflet de génération de la carte interactive (ici l’objet route au format sf). On peut choisir d’ajouter des fenêtres contextuelles (pop-up), par exemple sous la forme d’une étiquette apparaissant au passage du curseur sur l’objet. Parmi les nombreux paramètres de mise en forme disponibles, les options color et weight permettent respectivement de contrôler la couleur et la taille (en pixel) des traits ;

• addProviderTiles() permet d’ajouter un fond de carte interactif d’un des principaux fournisseurs (OpenStreeMap, CartoDB, Stamen, Thunderforest, etc.). La liste complète est accessible via la commande names(providers).

library(leaflet)
leafMap <- leaflet(data = route) %>%
  setView(lat = lat3M, lng = lon3M, zoom = 10) %>%
  addPolylines(popup = ~paste("Durée : ", round(duration/60)," minute(s)"), color = "#e31a1c", weight = 2) %>%
  addProviderTiles(providers$CartoDB.Positron)
leafMap

Nous pouvons également choisir de représenter les étapes du trajet par des couleurs différenciées selon le mode de déplacement. Dans un premier temps, nous associons une couleur (de la palette Set1 proposée dans la librairie RColorBrewer) par mode :

mycol <- colorFactor(
  palette = 'Set1',
  domain = route$leg_mode
)

leafMap <- leaflet(data = route) %>%
  setView(lat = lat3M, lng = lon3M, zoom = 10) %>%
  addPolylines(popup = ~paste("Durée : ", round(duration/60)," minute(s)"), color = ~mycol(leg_mode), weight = 2) %>%
  addProviderTiles(providers$CartoDB.Positron)
leafMap

Nous allons enfin choisir d’adapter le contenu des fenêtres contextuelles aux étapes du trajet, par exemple en affichant le mode de transport et la durée de l’étape. Pour séparer ces deux types de contenus informationnels (que nous afficherons en gras grâce à la commande html <strong></strong>), nous utiliserons la commande html <br> (break line) afin de créer un saut de ligne.

leafMap <- leaflet(data = route) %>%
  setView(lat = lat3M, lng = lon3M, zoom = 10) %>%
  addPolylines(popup = ~paste("<strong>Durée de l'étape :</strong> ", round(leg_duration/60)," minute(s)<br>","<strong>Mode :</strong>", leg_mode), color = ~mycol(leg_mode), weight = 2) %>%
  addProviderTiles(providers$CartoDB.Positron)
leafMap

6.1 Isochrones d’accessibilité

Les cartes d’isochrones représentent des zones d’accessibilité égale (en distance ou en temps de trajet notamment) à partir d’un certain point de départ. Elles figurent généralement plusieurs zones d’accessibilité, afin de représenter les différentiels croissants de coût du trajet à mesure que l’on s’éloigne du lieu d’intérêt.

iso_gareStRoch <- otp_isochrone(otpcon = myOtpcon,
            fromPlace = c(3.880727, 43.604937),
            mode = c("WALK","TRANSIT"),
            maxWalkDistance = 2000,
            date_time = as.POSIXct("2023-04-25 08:00:00"),
            cutoffSec = c(15, 30, 45, 60, 75, 90) * 60 ) 

iso_gareStRoch$minutes = iso_gareStRoch$time / 60 

mycol_2 <- colorFactor(
  palette = 'Reds',
  domain = iso_gareStRoch$minutes
)

leafMap <- leaflet(data = iso_gareStRoch) %>%
  setView(lat = 43.604937, lng = 3.880727, zoom = 10) %>%
  addPolygons(stroke=FALSE,
              color = ~mycol_2(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1) %>%
  addProviderTiles(providers$CartoDB.Positron) 
leafMap

leafMap <- leaflet(data = iso_gareStRoch) %>%
  setView(lat = 43.604937, lng = 3.880727, zoom = 10) %>%
  addPolygons(stroke=FALSE,
              color = ~mycol_2(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1) %>%
  addProviderTiles(providers$CartoDB.Positron) %>%
  addLegend("bottomright", pal = mycol_2, 
            values = ~minutes,
    title = "Temps d'accès",
    labFormat = labelFormat(suffix = " min"),
    opacity = 1
  ) 
leafMap

iso_gareStRoch_velo <- otp_isochrone(otpcon = myOtpcon,
            fromPlace = c(3.880727, 43.604937),
            mode = "BICYCLE",
            maxWalkDistance = 2000,
            date_time = as.POSIXct("2023-04-25 08:00:00"),
            cutoffSec = c(15, 30, 45, 60, 75, 90) * 60 ) 

iso_gareStRoch_velo$minutes = iso_gareStRoch_velo$time / 60 

mycol_3 <- colorFactor(
  palette = 'Blues',
  domain = iso_gareStRoch_velo$minutes
)

leafMap <- leaflet() %>%
  setView(lat = 43.604937, lng = 3.880727, zoom = 10) %>%
  addPolygons(data = iso_gareStRoch,
              stroke=FALSE,
              color = ~mycol_2(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1, 
              group="TRANSIT") %>%
  addPolygons(data = iso_gareStRoch_velo,
              stroke=FALSE,
              color = ~mycol_3(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1, 
              group="VELO") %>%
  addProviderTiles(providers$CartoDB.Positron) %>%
  addLayersControl(
    overlayGroups = c("TRANSIT", "VELO"),
    options = layersControlOptions(collapsed = FALSE)
  )
leafMap

leafMap <- leaflet() %>%
  setView(lat = 43.604937, lng = 3.880727, zoom = 10) %>%
  addPolygons(data = iso_gareStRoch,
              stroke=FALSE,
              color = ~mycol_2(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1, 
              group="TRANSIT") %>%
  addPolygons(data = iso_gareStRoch_velo,
              stroke=FALSE,
              color = ~mycol_3(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1, 
              group="VELO") %>%
  addProviderTiles(providers$CartoDB.Positron) %>%
  addLayersControl(
    overlayGroups = c("TRANSIT", "VELO"),
    options = layersControlOptions(collapsed = FALSE)
  ) %>%
  addLegend("bottomright", pal = mycol_2, 
            values = iso_gareStRoch$minutes,
            title = "Temps d'accès (TC/marche)",
            labFormat = labelFormat(suffix = " min"),
            opacity = 1,
       group="TRANSIT"
  )  %>%
  addLegend("bottomleft", pal = mycol_3, 
            values = iso_gareStRoch_velo$minutes,
    title = "Temps d'accès (vélo)",
    labFormat = labelFormat(suffix = " min"),
    opacity = 1,
    group="VELO"
  ) 
leafMap

6.2 Nombre de déplacements réalisables dans un intervalle de temps

L’analyse proposée ici vise à qualifier l’offre de transport en commun entre une ou plusieurs origine(s) en direction d’une destination à partir de la mesure du nombre de déplacements réalisables et de leurs durées. Cette analyse d’accessibilité sous contrainte horaire s’inscrit dans le cadre théorique et méthodologique de la Time-Geography (par exemple : Chapelon (2016) ; Conesa (2012) ; L’Hostis et al. (2004) ; …).

A titre d’exemple, nous développons un programme permettant de compter tous les déplacements possibles via le réseau de la TAM à partir des 30 mairies de la métropole (hors Montpellier) pour une arrivée entre 7h et 9h à la Gare Saint-Roch. L’objectif est d’évaluer la qualité de l’offre de transport théorique à l’heure de pointe du matin (les retards potentiels liés aux accidents de circulation, aux travaux, etc. ne sont pas pris en compte).

Mairies <- read.csv("data/mairies_3M.csv", header=TRUE)
head(Mairies)

  AAV2020   AN BV2012 DEP DEPCOM DOM      EPCI    DCIRIS LAMBERT_X LAMBERT_Y
1      12 2021  34022  34  34022   A 243400017 340220102  781729.9   6285175
2      12 2021  34058  34  34027   A 243400017 340270000  782250.0   6292750
3      12 2021  34172  34  34057   A 243400017 340570103  772475.6   6281921
4      12 2021  34058  34  34058   A 243400017 340580101  779478.3   6287040
5      12 2021  34172  34  34077   A 243400017 340770101  771637.0   6284634
6      12 2021  34088  34  34087   A 243400017 340870000  757131.6   6272537
   QP QUALI_IRIS QUALI_QP QUALI_QVA QUALI_ZFU QUALI_ZUS QUALITE_XY QVA REG SDOM
1 CSZ          1        X         X         X         X      Bonne CSZ  76   A1
2 CSZ          X        X         X         X         X Acceptable CSZ  76   A1
3 CSZ          1        X         X         X         X      Bonne CSZ  76   A1
4 CSZ          1        X         X         X         X      Bonne CSZ  76   A1
5 CSZ          1        X         X         X         X      Bonne CSZ  76   A1
6 CSZ          X        X         X         X         X      Bonne CSZ  76   A1
  TYPEQU UU2020 ZFU ZUS
1   A129  34302 CSZ CSZ
2   A129  34133 CSZ CSZ
3   A129  34701 CSZ CSZ
4   A129  34206 CSZ CSZ
5   A129  34701 CSZ CSZ
6   A129  34214 CSZ CSZ

Mairies <- st_as_sf(Mairies,
                    coords = c("LAMBERT_X","LAMBERT_Y"),
                    crs = st_crs(2154))

Mairies <- st_transform(Mairies, 4326)

temps_limite <- as.POSIXct("2023-04-19 09:00:00")
temps_debut <- as.POSIXct("2023-04-19 06:00:00")

end_places <- c(3.88040,43.60508)
from_places <- as.matrix(cbind(st_coordinates(Mairies)[,1], st_coordinates(Mairies)[,2]))

route_boucle <- data.frame()

while(temps_debut < temps_limite){
  tryCatch({
    resultats <- otp_plan(otpcon=myOtpcon, 
                          fromPlace = from_places,
                          toPlace = end_places,
                          mode = c("TRANSIT","WALK"),
                          date_time = temps_debut,
                          maxWalkDistance = 1000,
                          get_geometry=FALSE)
    temps_debut <- temps_debut + 60
    route_boucle <- rbind(route_boucle, resultats)
  }, error = function(e) {
    print(paste("Erreur dans la boucle :", e$message))
  })
}

route_boucle <- route_boucle[!(route_boucle$endTime < "2023-04-19 07:00:00" | route_boucle$endTime > "2023-04-19 09:00:00"), ]

tableau_resultat <- route_boucle %>%
  semi_join(
    route_boucle %>%
      distinct(fromPlace) %>%
      select(fromPlace)
  ) 

tableau_resultat <- tableau_resultat %>%
  group_by(fromPlace, endTime) %>%
  summarise(duree_moy = mean(duration/60, na.rm = TRUE))%>%
  group_by(fromPlace) %>%
  summarise(nb_endTime = n_distinct(endTime), 
            duree_moy = mean(duree_moy, na.rm = TRUE))

ggplot() + geom_histogram(aes(x = tableau_resultat$duree_moy),
                          bins = 9,
                          color="black", 
                          fill="lightblue") +
    labs(title="Histogramme", x="Temps de trajet moyens", y = "Nombre de mairies") +
    theme_classic() # thème de fond (ici "classic")

library(stringr)
tableau_resultat$x <- word(tableau_resultat$fromPlace, 1, sep=",")
tableau_resultat$y <- word(tableau_resultat$fromPlace, 2, sep=",")
tableau_resultat <- st_as_sf(tableau_resultat, coords = c("y","x"),
                    crs = st_crs(4326))

tableau_resultat <- st_transform(tableau_resultat, 2154)
EPCI_3M <- st_transform(EPCI_3M, 2154)

library(mapsf)
mf_init(x = tableau_resultat, theme = "iceberg", expandBB= c(0.3, 0.3, 0.3, 0.3))
mf_map(EPCI_3M, add = TRUE)
mf_map(tableau_resultat,
       type = "prop_choro",
       var = c("nb_endTime","duree_moy"),
       inches = 0.15,
  border = "grey50",
  lwd = 1,
  leg_pos = c("left", "right"),
  leg_title = c("Nombre", "Temps\nmoyen\n(en min)"),
  breaks = "equal",
  nbreaks = 9,
  pal = "Greens",
  leg_frame = c(TRUE, TRUE))

mf_layout(
  title = "Trajets mairies vers gare St-Roch",
  #subtitle = "Arrivée prévue entre 7h et 9h",
  credits = paste0(
    "Sources: OTP et TAM 2022 \n",
    "mapsf ",
    packageVersion("mapsf")
  ),
  frame = TRUE
)

otp_stop()